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In this release, the binder has been changed substantially; a considerable improvment in 
performance has been realized as a result The bulk of the processing is now performed by 
the binder prior to loading; the binder therefore operates as a separate subsystem, which is 
quite similar in nature to the compiler (it deals with entire modules instead of individual 
statements). 

Input to the binder consists of a set of compiled modules and a configuration description 
which specifies what modules should be included and how they are to be bound. Output of 
the binder is a single binary configuration description (bcd) in which bindings among its 
modules are resolved and encoded in a form that can be quickly patched up by the loader. 

Preparation of input for the binder is described in other documentation accompanying this 
release (in the language manual and the compiler memo), as is the processing of its output 
by the loader (the New command). This memo outlines the operation of the binder and the 
various options that are available. 

Running the Binder 

The binder processes a configuration description (the source) and creates a bcd file (and 
optionally other files containing code and symbol tables). It takes commands either from 
the command line or interactively from the keyboard. Commands are of the form 

source[/s file/s file/s] 

where [] indicates optional parts. The valid switches are 

/d - enter debugging mode 

/c - copy code segments to this file 

/o - give this name to the output bcd file 

/s - copy symbol segments to this file 

/x - copy compressed symbols to this file 

/g - begin processing the precceding files 



While debugging, the "normal" mode of operation is to not copy code or symbol segments 
into the bcd (the default; no switches), but to leave them in the files generated by the 
compiler. This saves disk space and requires the least binding time; on the other hand, 
loading and debugging (and code swapping) may be a bit slower, since there are many more 
files to be looked up and accessed. 
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For "distribution'*, code and/or symbols can be copied into the output file by using the 
corresponding switch on the source file name (not on the output file name). Alternately, 
they can be copied into different code or symbols files by giving the file name and switch 
following the source file name. It is a good idea to package the symbols of your subsystem 
into a separate file, so that they will not take up disk space when they are not in use. 
(Because the new binder deals only with interfaces, symbol tables are not required for 
binding or loading. Of course, they are required for meaningful debugging.) 

There is also an option for compressing the symbol tables as they are copied. In this mode, 
only public symbols declared in the global frame (including procedures and signals and their 
parameters and results) are included. Private symbols and variables local to procedures are 
not copied. This option allows limited but usually adequate debugging, and will 
substantially reduce the size of the symbols file (typically by 50%). 

Normally a command to the binder is terminated with an end-of-line. In order to specify 
more than one command using the command line form of input, the /g switch (for *'go'*) 
may be used to replace the end-of~line. Simply add the /g switch to the last file name of 
each command. (This option is not available for interactive keyboard input.) 

The first file name is aKvays the source configuration description. The last occurance of a 
/c, /o or /s file will prevail, and extra filenames are ignored. Default extensions are 
"config" for source, "bod" for output, "code" for code and "symbols" for symbols. Default 
output is to source. bed. Examples: 



foo 



foo/c 



Read foo.config and write the resulting BCD on foo. bed. This is the "normal" 
debugging mode since it is the fastest and requires the least disk space. 



Read foo.config, write foo. bed. Copy all code segments into foo. bed. Leave all 
symbol segments as they were in the input files. This is a possible "distribution" 
mode. 



foo/es 



Read foo.config, write foo. bed. Copy all code and symbol segments into foo. bed. 
This is also a possible distribution mode, if debugging will be required. 

foo/e foo/x 

Read foo.config, write foo. bed. Copy all code segments into foo. bed; compress all 
symbol segments into foo.symbols. By packaging all of the symbols in a single file, 
you minimize the risk of getting an incorrect version of some symbol table. 

foo.cd/e foo.sym/s foo.bound/o 

Read foo.ed, write foo. bound. Copy all code segments into foo. bound and all 
symbol segments into foo.sym. 

foo.ed/c foo.sym/sg bar/c 

Read foo.ed, write foo. bed. Copy all code segments into foo. bed and all symbol 
segments into foo.sym. Then read bar.eonfig and write bar.bed. Copy all its code 
into bar.bed. 
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Because of the large number of options available, it is doubly important to maintain file 
consistency. Appropriate version checks are included in the binder, the loader, and the 
debugger. Copying code into a file other than the BCD file is supported, but probably not 
useful. 

Current Limitations 

The DIRECTORY clause in a configuration description should be used only when the name of a 
module or configuration differs from the name of its file. Do not make directory entries 
for interface (definitions) files. 

The output BCD file can be renamed. The code and symbols files cannot (since the bcd 
contains the names of these files in its internal tables). 

Forcing code and symbols into the same file (other than the bcd file) is not yet 
implemented. 

A configuration must tell the truth about what it imports and exports, i.e. everything 
imported or exported by a configuration must actually be imported or exported by a 
contained module or configuration. 

Multiple instances of nested configurations are not yet implemented. You can get around 
this by binding the nested configuration in a separate step. 

The Binder will occasionally get confused after several errors and give up. Try fixing the 
errors and starting over. There is currently no source line output with error messages. 

Estimated running time: five seconds for initialization plus one second per included file 
(module or configuration). Add one second per module to copy code and two seconds per 
module to copy symbols. 



